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We present a new type system combining refinement types and the expressiveness of intersection 
type discipline. The use of such features makes it possible to derive more precise types than in the 
original refinement system. We have been able to prove several interesting properties for our system 
(including subject reduction) and developed an inference algorithm, which we proved to be sound. 


1 Introduction 

Refinement types ifTTl state complex program invariants, by augmenting type systems with logical pred¬ 
icates. A refinement type of the form {v : B | 0} stands for the set of values from basic type B restricted 
to the filtering predicate (refinement) 0. A subtyping relation exists for refinement types, which will 
generate implication conditions: 

r;v : B h 0 ^ i/r 

r h {v : B I 0} <: {v : B I i/r} 

One idea behind the use of such type systems is to perform type-checking using SMTs (Satisfability 
Modulo Theories) solvers ifT^ . discharging conditions as the above 0 => i/r. However, the use of arbitrary 
boolean terms as refinement expressions leads to undecidable type systems, both for type checking and 
inference. 

Liquid Types ifTSlfTTl present a system capable of automatically inferring refinement types, by means 
of two main restrictions to a general refinement type system: refinement predicates of some terms are 
conjunctions of expressions exclusively taken from a global, user-supplied set (denoted Q) of logical 
qualifiers (simple predicates over program variables, the value variable v and the variable placeholder 
*); and a conservative (hence decidable) notion of sub typing. 

Despite the interest of Liquid Types, some situations arise where the inference procedure infers 
poorly accurate types. For example, considering Q = {v > 0, V < 0} and the term neg = Xx. —x. Liquid 
Types infer for neg the type x : {0 < v A 0 > v}^{0 < V AO > v} (throughout this paper we write 
{0} instead of {v : B | 0} whenever B is clear from the context). This type cannot be taken as a precise 
description of the neg function’s behavior, since it is not expressed that for a positive (resp. negative) 
argument the function returns a negative (resp. positive) value. With our system we will have for neg the 
type (x : {v > 0} {v < 0}) D (x : {v < 0} {v > 0}). 

We introduce Liquid Intersection Types, a refinement type system with the addition of intersection 
types (21131. Our use of intersections in conjunction with refinement types is motivated by a problem 
clearly identified for Liquid Types: the absence of most-general types, as in the ML tradition. Our use of 
intersections for refinement types draws inspiration from |hj|, since this offers a way to use jointly detailed 
types and intersections. Though, integrating this expressiveness with refinement types and keeping the 
qualifiers from Q simple (which must be provided by the programmer) implies the design of a new type 
system. 


Jakob Rehof (Ed.): Intersection Types and Related Systems (ITRS) 
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M,N 



Terms: 


1 

X 

variable 


1 

c 

constant 


1 

Xx.M 

abstraction 


1 

MN 

application 


1 

\elx = M\r\N 

let-binding 


1 

[Aa]M 

type abstraction 


1 

[t]M 

type instantiation 

0 



Liquid refinements: 


1 

q 

qualifier from Q 


1 

T 

true (empty refinement) 

B 



Base types : 


1 

int 

integers 


1 

bool 

booleans 

t{^) 



Pretype skeleton 


1 

{v.B\3i] 

base refined type 


1 

X : x{i%) -)• x{!%) 

function 


1 

x{^) n x{^) 

intersection 


1 

a 

type variable 

a(^) 



Pretype scheme skeleton : 


1 

x(^) 

mono pretype 


1 

Va.cj(M) 

pretype scheme 

T 



Simple types: 


1 

B 

basic type 


1 

a 

type variable 


1 

Ti^T2 

functional type 


::= 

x{£g)T,a {^):: T 

Well-founded pretype, scheme 

T,(7 

::= 

x{E),a{E) 

Refinement Intersection Type, Scheme 

T,d 

::= 


Liquid Intersection Type, Scheme 

r 

::= 


Environment: 


1 

0 

empty 


1 

r;x ; a 

new binding 


Figure 1: Syntax 

Besides the new type system, another contribution of this work is a new inference algorithm for 
Liquid Intersection Types. 

This paper is organized as follows. Section |2] presents the designed type system, with a focus on the 
language syntax, semantics and typing rules, as well as a soundness result. The type inference algorithm 
is introduced in section [3] Finally, in section |4] we conclude with final remarks and explain some possible 
future work. 

2 Type system 

2.1 Syntax and semantics 

Our target language is the A-calculus extended with constants and, as in the Damas-Milner type system, 
local bindings via the let constructor. We assume the Barendregt convention regarding names of free 
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and bound variables [T], and identify terms modulo a-equivalence. The syntax of expressions and types 
is presented in Figure [T] We will use FV (M) and BV (M) to denote the set of free and bound variables of 
term M, respectively. These notions can be lifted to type environments, as FV (F), resp. BV (F), denoting 
the free variables, resp. the bound variables, of refinement expressions for every typed bound within F. 

The set of constants of our language is a countable alphabet of constants c, including literals and 
primitive functions. We assume for primitive functions the existence of at least arithmetic operators, a 
fixpoint combinator f ix and an identifier representing if -then-else expressions. The type of constants 
is established using a mapping ty{c), assigning a refined type that captures the semantic of each constant. 
For instance, to an integer literal n it would be assigned the type {v : int \ v = n}. Note that refinements 
may come from the user defined set Q or from the constants and sub-derivations. In the latter case the 
refinement expressions are arbitrary expressions from E. 

We use t{M) and a{^) to denote pretypes and pretype schemes, respectively (this notion of pretypes 
goes back to |[T3l ). which stand for type variables, basic and functional refined types, intersection of 
pretypes and polymorphic pretypes. The notation x : Ti —> T 2 will be preferred over the usual n(x : Ti).T 2 
for functional dependent types, meaning that variable x may occur in the refinement expressions present 
in T 2 . An intersection in pretypes (denoted by n) indicates that a term with type Ti (.^) D T 2 (^) has both 
type Ti (.^) and Z2i^), respecting the possible refinement predicates figuring in these types. We assume 
the 'n' operator to be commutative, associative and idempotent. 

A well-founded pretype (resp. well-founded type scheme) is a pretype (resp. o{Ff)) for such 
that :: T (resp. o{Ff) :: T), for some T (T stands for simple types for the rest of this document). 
The well-founded relation a{f^) ::T is inductively defined by: 

::-FUN ::-V ::-n 

::-Var Xxi^)--Tx x{dg)::T ::-Ref a{d?)::T X 2 {^)--T 

a :: a {x: ^ t{^))::Tx^T {v : B \ :: B Va.a{^)::T Xi{d?)riX2{^)T 

Using this relation guarantees that intersection of types are at the refinement expressions only, i.e. for 
n CJ 2 (.^) both Gi{M) and 02 ( 1 ^) are of the same form, solely differing in the refinement predi¬ 
cates. 

To describe the execution behavior of our language we use a small-step contextual operational se¬ 
mantics, whose rules are shown in Figure |2l The relation M N describes a single evaluation step from 
term M to N. The rules [S’ — p], [S — Let] and [S — Compat] are standard for a call-by-value ML-like 
language. The rule [S -Constant] evaluates an application with a constant in the function position. This 
rule relies on the embedding [[•]] of terms into a decidable logic fl^ (the definition of this embedding, as 
well as the details of the used logic, will be made clear in next section). 

2.2 Typing rules 

We present our typing rules via the collection of derivation rules shown in Figure [3] We present three 
different judgments: type judgment, of the form F Fq M : a meaning that term M has type a under en¬ 
vironment F, restricted to the qualifiers contained in Q, i.e., only expressions from the set Q can be used 
as refinement predicates for the following terms: let bindings, A-abstractions and type instantiations; 
subtype judgment F ai ^ G 2 , stating that ai is a subtype of G 2 under the conditions of environment 
F; and the well-formedness judgment F a indicating that variables referred by the refinements of 
G are in the scope of corresponding expressions. The well-formedness judgment can be lifted to well- 
formedness of environments, by stating that an environment is well-formed if for every binding, types 







M. Pereira, S. Alves & M. Florida 


27 


V 




Values: 


1 

c 


constant 


1 

Xx.M 

abstraction 

Contexts 





C 



Contexts : 


1 

[] 


hole 


1 

CM 

left application 


1 

VC 

right application 


1 

let X = C in M 

let-context 

Evaluation 




M N 

cV 


Icl(V) 

[to — Constant] 

{XxM)V 


[V/x\M 


i^-P] 

x = V in M 


\v/x]M 


[,^-Let] 

C[M] 


C[A] if M-^N 

[#- 

Compat] 


Figure 2: Small-step operational semantics. 


are well-formed with respect to the prefix environment. This well-formedness restriction implies the 
absence of the structural property of exchange in our system, since by permuting the bindings in F one 
could generate an inconsistent environment 

The rule [APP] conforms to the dependent types discipline, since the type of an application MN is 
the return type of M but with every occurrence of x in the refinements substituted by N. 

Another point worth mentioning is the distinction made when the type of a variable is to be retrieved, 
rules [Var-B] and [VAR]. Whenever the type of the variable z is an intersection of refined basic type we 
ignore these refinements and assign z the type {v : B | V = z}, for some basic type B. This is inspired on 
the system of Liquid Types lITSll . since this assigned refined type is very useful when it comes to use in 
subtyping, especially with the rule [^-Base]. When this is not the case, the type of a variable is the one 
stored in F. 

One novel aspect of this system is the presence of the [INTERSECT] rule, which allows to intersect 
two types that have been derived for the same term. The use of this rule increases the expressiveness of 
the types language itself, since more detailed types can be derived for a program. 

The subtyping relation presents some typical rules for a system with intersection types. These allow 
to capture the relations at the level of intersections in types, with no concern for the refinements of the 
two types being compared. On the other side, comparing two refined base fypes reduces to the check of 
an implication formula between the refinement expressions. Our system uses a decidable notion of im¬ 
plication in the rule [^-Base], by embedding environments and refinement expressions into a decidable 
logic. This logic contains at least equality, uninterpreted functions and linear arithmetic. This is the core 
logical setting of most state-of-the-art SMT solvers. The embedding [M]] translates the term M to the 
correspondent one in the logic (if it is the case M is a constant or an arithmetic operator), or if M is a 
A-abstraction or an application encodes it via uninterpreted functions. The embedding of environments 
is defined as 


ri^/\{([£ilA...Ap„l)[x/v]|x:{v:B|£i}n...n{v:B|£„}€r} 

Given that every implication expression generated in rule [^-Base] is decidable, it is then suitable 
to be discharged by some automatic theorem proven So, type-checking in our system can be seen as a 
typing-and-proof process. 
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Liquid Intersection Type checking 

Sub Intersect 

rhoMicJi ri-^(72 rh^MiTi ri-g,M:T 2 TinT2::7’ 


r hU M ; (7 


r ho M: ff2 


r hg, M: Ti n t2 


Var-B Var 

r(x) = Ti n ... n T„ l </<«) r(x) not abase type r(x) :: T 

rh^x:{v:B|v = x} T\-^x:T{x) 

Apr Fun 

rhgM: (x: ^ t) r\~'AN:tx r-,x: ix\-QM : f 


f:: r 


rhg,MA^: [N/x]t 


r ho Xx.M \ {x \ Xx —^ f) 


Let 


Const 


r hh c : fy(c) 


rhgMia r;x:( 7 hgA?:f rh"f 

r ho let X = M in : f 


Gen Inst 

rhg,M;(j a^r rhg,M:Va .(7 Th^f Shape(f) = T 


r ho [Aa]M : Va.cJ 


rhU [T]M-.[xla\a 


Subtyping 


a-Base 

Valid(|rl A (|£il A ... A |£„I) ^ (|£;i A ... A )) 
{v:B\Ei}n...r\{v:B\En}-<{v:B\E[}n...n{v:B\E'„} 

a-Intersect-Fun ^-Elim 


r h'^ ( 7 l ^ 02 


r h (x: Tc Ti) n (x: Tf T2) A (x: T;c -)> Ti n T2) F h Ti n T2 -< T, 


*€{1,2} 


a-Fun 

r h*^ -< Xx F;x -.x'xF^ X ^x' 

FF'^ x-.Xx^ X <x-.xl^ x' 


A-INTERSECT 

r h*^ T ^ T1 r h'^ T ^ T2 


r h T ^ Ti n T2 


a-Var 


Fh" a ^ a 

A-Poly 

F h'^ (Ji ^ O2 
Fh*^ Va.cTi ^ Va.(72 


Well formed types 


WF-B 

F; V : B h'^ £ : bool 
Fh^ {v :B|£} 

WF-Fun 
F;x: T;c h'^ T 

F h'^ X: Tv T 


WF-Var 


Fh" a 


WF-POLY 

Fh^ (j 


FH'Va.cJ 


WF-Intersect 
F h^ Ti F h^ T 2 

F h'^ Ti n T2 


Fh" (7 


Figure 3: Typing rules for Liquid Interseetion Types. 







M. Pereira, S. Alves & M. Florida 


29 


We show an example of a derivation for the term Xx. — x, assuming Q = {v > 0,v < 0}- With 
r = X : {v > 0}, consider: 




Const -p- 


Var-B 


r(A) = {v > 0} Valid(x > OA V = x=> T) 


ri-Qx: {v =x} 


r {v = x} ^ int 


(y :int^{v = -y}) 


r hU X : int 


—X : {v = —x} 


^-Base 

Sub 


and: 


: 


Valid(x >0Av = -x^V<0) 
rh^{v = -x}^{v<0} 
rh^-x:{v<0} 
l-Q Xx. —X : (x : {v > 0} —{v < 0}) 


-<-Base 

Sub 

Fun 


We can also derive Hq Xx. — x : (x : {v < 0} —> {v > 0}) (similarly to the previous derivation, with 
the corresponding < and > symbols changed). Naming that derivation 3)i, we finally have: 


^2 

Fq Ax. -X : (x : {v > 0} {v < 0}) n (x : {v < 0} {v > 0}) 


Intersect 


We omit the well-formedness and well-founded sub-derivations, since they are trivially constructed and 
use int to denote the type {v : int \ T}, that is, the common type for integer values. 


2.3 Properties 

In order to prove soundness properties for our system we follow the approach of ifTSlfTTll . The decidable 
notion of implication checking employed by the subtyping rules is a problem when it comes to prove a 
substitution lemma. So, instead we prove subject reduction for a version of the system with undecidable 
subtyping and unrestricted expressions in refinement predicates. The typing judgment in this system will 
be denoted by T M : a, and the inference rules are presented in Figures |4] and [5i Then, we show 
that any derivation in the decidable system has a counter-part in the undecidable one. We present in this 
section the more interesting steps employed during the proof of subject reduction for our type system. 
The detailed proofs can be found in lUdll . 

Definition 1 (Constants) Each constant c has a type ty{c) such that: 

1. 0 ty{c); 

2. if c is a primitive function then it cannot get stuck, thus ifTP^cv then [[c]](v) is defined and if 
r cM : a and [c]] (M) is defined then F [c]] (M) : a; 

3. ifty{c) is {v : B\(p} then (p = v = c. 

Definition 2 (Embedding) The embedding [[•]] is defined as a map from terms and environments to for¬ 
mulas in the decidable logic such that for all r,E,E' ifF E : bool, F E': bool, Valid([[r]] A [E]] =F 
E'), then TP^E^ E'. 
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Refinement Intersection type checking 

Sub 

r M; ( 7 i r ^ ff2 r (j2 

r M ; (72 

VAR-B 

r(x) = Ti n... n T„ q :: B {\/i: l < i < n) 
Y\-^x-.{v:B\v=x} 

Apr 

r M : (x: T, ^ t) T A?: 

rh^MA^: [N/x]x 

Const 

r c : fy(c) 

Gen 

TV-^ M\ a a^T 
r h'^ [Ka\M : Va.cT 

Implication 

Imp 

r £ : bool r £'; bool 


r M : (7 


Intersect 

rh'^MlTi rh^M:T2 X\C\X2'.'.T 

r M: Ti n t2 

Var 

r(x) not a base type r(x) T 

r X: r(x) 


Fun 

T-,X\ XxY'^ M X rh'^Tf— XV.T 



Ffh 

Xx.M :{x:Xx^x) 

Let 



c 

l-H 

: 0 

T-,x:oY^N:x FF^t 


F F'^ let X = M in A^ : x 

Inst 



FF^M: 

Va.(7 

FF^T Shape(T) = r 


rh^ [T]M-. [x/a\a 


TY^E^E' 


Vp.(r 1= p and p(£') T implies p{E') A T) 
rh^£=^£' 


Subtyping 


r h'^ ( 7 i ^ 02 


a-Base 

F; V : Z? Ei A ... AE„ ^ E[ A ... AE[^ 
rh^ {v;B|£i}n...n{v:B|£„} -< {v;B|£;}n...n{v ;B|£;} 

a-Intersect-Fun a-Elim 

r h'^ (x : Tt -)■ Ti ) n (x : Tt T2) ^ (x : Tf Ti n T2) r Ti n T2 -< T, * ^ ^ 


a-Fun 

r h'^ -< Xx T\X -.x'xY^ X ^x' 

r (x : Tf t) ^ (x: -)> t') 


A-Var 
rh^ a ^ a 


A-INTERSECT 

r T ^ T1 r h'^ T ^ T2 


r h'^ T ^ Ti n T2 


A-Poly 

r ( 7 i ^ 02 

Va.(7i ^ Va.(72 


Figure 4: Refinement Interseetion typing rules 
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Well formed types 


Consistent substitutions 


1 


WF-B 

T; V : B 0 : bool wf-Var 

rh^{v;B|0} rh^ a 


WF-FUN 

r;x : T;c T 

r (x : T, ^ t) 

WF-Intersect 

r Ti r t 2 
r Ti n t2 


WF-POLY 

rh^ (j 
rh^ Va.cj 


CS-Ext 

cs-empty r 1= p 0 h'^ y ; P (a) 

0|=0 r;x : (J p; [y/x] 


rh^ (7 


rhP 


J 


Figure 5: Rules for well formed Refinement Interseetion Types and eonsistent substitutions. 


Definition 3 (Substitution) We define substitution on types, p{o), as follows: 


p(a) 

piiv.BlE}} 

p(x: 

p(Va.a) 

p(TinT2) 


a 

{v:B\p{E)} 
x:p(T^) ^P(t) 
Va.p(a) 
p(Tl)np(T2) 


A substitution ean be lifted to typing eontexts as expeeted: 

p(0) = 0 

p(r;x:a) = p(r);x:p(a) 


Definition 4 (Domain of a substitution) The domain of a substitution, Dom(p), is defined as follows: 


Dom(0) = {} 

Dom(p;[y/x]) = Dom(p)U{x} 

Lemma 1 (Substitution permutation) T/^F ^ Pi;p 2 then 
L Dom(pi) n Dom(p 2 ) = 0; 

2. for all Liquid Intersection Type a, pi;p 2 (a) = p 2 ;pi(cj). 


Proof 1. By induetion on the derivation F \= p\,p 2 , splitting eases on whieh rule was used at the 
bottom. 


2. By induetion on the strueture of a. 


□ 
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Lemma 2 (Well-formed substitutions) 

1. ^ r 1= Pi;p2 then there are ri,r2 such that T = ri;r2, Dom(pi) = Dom(ri), Dom(p2) = 
Dom(r2); 

2. ri;r 2 |=pi;p2,Dom(pi) =Dom(ri),Dom(p2) =Dom(r2) ijfTi \= pi, pir 2 ^P 2 . 

Proof. 1. By induction on the structure of r. 

2. By induction on the structure of r 2 . □ 

Corollary 1 (Well-formed substitutions) 

ri;;c: a:,;r2 ^pi;[yxA];P2 ^pi, 0 h L,: pi(a^), pp [y,/x](r2) |= P2. 

Proof. Corollary of Lemma |2l □ 

Lemma 3 (Weakening) Let 

T = TuT2 
r = ri;;c: opSi 
x^TV{T2) 

then: 

1 . ifV pu\y/x\, P2, then L |= pi;p2; 

2. ifTV-^E^ E', then T'E ^ E'; 

3. ifY ai ^ 02, then T' Oi ■< O2; 

4 . ifY a, then Y' a; 

5. ifY M : a, then H M : 0. 

Proof. By simultaneous induction on the derivations of the antecedent judgments. □ 

Lemma 4 (Substitution) If 

Li y : a' 

r = ri;.v: a';r 2 

Y' = Yp,[V/x]Y2 

then: 

1 . ifY'^pu^/x]p2,thenY''^pi\p2; 

2 . ifY Y^E^ E', then Y' [V/x]E ^ [V/x]E'; 

3. ifY ai ^ 02, then Y' [y /x]oi -< [y /x]o2; 

4 . ifY 0, then Y' [yA]a; 

5. if 0 :: T, then [y /x]o :: T; 

6 . ifY M : a, then F' M : 0. 

Proof. By simultaneous induction on the derivations of the antecedent judgments. □ 

Theorem 1 (Subject reduction) IfYY^M-.o and M N, then YY''^ N ■. a. 

Proof. By induction on the derivation F M : a, splitting cases on which rule was used at the bottom. 
We give here the cases for [INTERSECT] and [APP]. 
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• case [Intersect]: By inversion 

r M : Ti 

r M : T2 

Ti nT2''T 

By IH 

r : Ti 

r : T2 

So, the following derivation is then valid 

rh^A^:Ti rh^A^:T2 TinT2::7’ 

Intersect -pr- 

r A^: Ti n t2 

• case [App] : By inversion 

r M : (x : Tt t) 

rh^A: 

- sub-case in which M is a context: For this case consider M M'. 

By IH 

r M': (x : T, ^ t) 

Given that M M', then MN M'N. 

The following derivation is then valid 

r M': (x : T;, ^ t) F A : 

^pp _ 

Fh^M'A: [A/x]t 

- sub-case in which A is a context: Similar to the previous one. 

- sub-case in which application is of the form cF: By pushing applications of rule [SUB] down, 
we can ensure rule [CONST] was used at the bottom of the derivation of the type for c. 

For this case, cF [[cl(F). 

By inversion 

F c : (x : t) 

F F : T, 

By Definition [U we have 

Fh^ IcK^) : [y/A^ 

which is the desired conclusion. 

- case in which application is of the form (Ax.M)F: For this case 

(Ax.M)F [F/x]M 

By pushing applications of the rule [SUB] down, we can ensure rule [Fun] is used at the 
bottom of the derivation of the type for Xx.M. 

By inversion 

F XxM : {x : t) 

rP<^V:Tx 
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By inversion on rule [Fun] 


X : Tjc M : T 


By Lemma|4] 


Fh^ [V/x]M:[V/x]z 


which is the desired conclusion. 


□ 


Theorem 2 (Over approximation) IfTL^M: o, then F M : a. 

Proof. The proof follows by straightforward induction on the typing derivation. At each case the key 
observation is that each Liquid Intersection Type is also a Dependent Intersection Type and for each rule 
in the decidable system there is a matching rule in the undecidable side. For the case of [-<-Base] we 
use Definition 1. 

Combining Theorems [U and |2] guarantees that at run-time, for every well-typed term, taking an eval¬ 
uation step preserves types. 


3 Type inference 

In this section we present our algorithmQ for inferring Liquid Intersection Types, Figure Before exe¬ 
cuting this algorithm we bind every sub expression using the let-in constructor. This transformation is 
closely related with A-Normal Forms Q and is performed to force types of intermediate expressions to 
be pushed into the typing context. The algorithm we propose is built upon three main phases: (i) we use 
the ML inference engine to get appropriate types, serving as type shapes for Liquid Intersection Types; 
(ii) for some particular sub-terms a set of constraints is generated, ensuring the well-formedness of types 
and that subtyping relations hold, in order to infer sound types; (iii) taking qualifiers from Q we solve 
fhe generafed consfrainfs on-the-fly, much like as in classical inference algorifhms. 

3.1 Using Damas-Milner type inference 

One key aspecf of our inference algorifhm is fhe use of fhe inference algorifhm im fo infer ML 
fypes. Given fhe facf fhaf a Liquid Infersecfion Type for a ferm is a refinemenl and infersecfions of 
fhe corresponding ML fype, fhe fypes inferred by W acf as shapes for our Liquid Infersecfion Types. 
Indeed, fhe function Shape(•) (figuring in fhe typing rules and in the inference algorithm) maps a Liquid 
Intersection Type to its corresponding ML type. For example. Shape ((x : {v = 0} ^ {v = 0}) D (x : 
{v > 0} —{v > 0})) = int int. 

In the inference algorithm, whenever W is called, we need to feed it with an environment containing 
exclusively ML types. This is done by lifting Shape(-) to environments, Shape(r), by applying it to 
every binding in F. 

The function Fresh(-, •) takes an ML type and the set Q as input and generates a new Liquid Inter¬ 
section Type that contains all the combinations of refinement expressions from Q. Taking for instance 
the ML type T = x : int ^ int (we assume we can annotate types with the corresponding abstraction 

'For some cases of the algorithm we use a temporary type, denoted by si . The only purpose of temporary types is to ease 
the notation as we explain in section lTS] 
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Inf er(r,;c,Q) 

Infer(r,c,Q) 

Inf er (r, Ajc.M, Q) 


Inf er(r,MA^,Q) 


Inf er (r, let x = M in Q) 


Infer(r,[Aa]M,Q) 
Infer(r, [7’]M,Q) 


if W (Shape(r),x) = B then {v.B\v = x} 

else r(x) 

ty{c) 

let (x : fi —7> f() n... n (x : ^ f') = Fresh(>^(Shape(r),lx.M),Q) in 

let t" = Inf er(r;x : in 

let = n I (jc: -S' fj) I r (x : fi -!> t[) n ... n (x : f„ f')I in 

n {(x: ^ f^) |x : ft ^ G ^,r;x : ft -< f{} 

let (x : Ti —>• t() n ... n (x : T„ —>• t') = Infer(r,M,Q) in 
let T = Inf er(r,A^,Q) in 

n[A^A]{T'|rhnT^T,} 

let f = Fresh(#'(Shape(r),let x = M in A^),Q) in 

let Ti = Inf er(r,M,Q) in 

let T 2 = Infer(r;x : Ti,A^,Q) in 

let jz/ = Pi {f-1 r f} in 

PI {f; I f; G £/,T-X : Tl l-n T2 -< f;} 

let (7 = Inf er(r,M,Q) in 

Va.cT 

let t' = Fresh(r,Q) in 
let Va.CJ = Inf er(r,M,Q) in 
let j 2 / = p|{T'|rhn t'} in 

a[jzf/a] 

Figure 6: Type inference algorithm 


variable, so it is easier to use with refinements) and Q = {v > 0, V < 0}, Fresh(r,Q) would generate 
the Liquid Intersection Type 

(x : {v > 0} -S' {v > 0}) n 

(x : {v > 0} -S' {v < 0}) n 

(x : {v < 0} -S' {v > 0}) n 

(x : {v < 0} -S' {v < 0}) 

3.2 Constraint generation 

The constraints generated during inference serve as a means to ensure that the subtyping and well- 
formedness requirements are respected. In the presentation of the algorithm we borrow the notations 
from the typing rules, with F a standing for a well-formedness restriction over a and F a -< a' 
constraining type a to be a subtype of a'. 

The well-formedness constraints are generated for terms where a fresh Liquid Intersection Type is 
generated (A-abstractions, let-bindings and type application). For a fresh generated Liquid Intersection 
Type, solving this kind of constraints will result in a type where the free variables of every refinement 
are in scope of the corresponding expression. 

The second class of constraints are the subtyping ones, capturing relations between two Liquid Inter¬ 
section Types. A constraint F a -< a' is valid if the type a' is a super-type of a, meaning that there is 
a type derivation using the subsumption rule to relate the two types. 

The well-formedness and subtyping rules (Figure O can be used to simplify constraints prior to their 
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solving. For instance, the constraint F Ti fl... n can be simplified to the set {F Ti,..., F T„}. 
On the other hand, the constraint F {x : Zi ^ Z 2 ) ^ {x ■ t'i ^ can be further reduced to F ^ Ti 

and r;x : T 2 ^ "fi- 

3.3 Constraint solving 

We now describe the process of solving the collected constraints throughout the inference algorithm. 
This process will reduce to two different validity tests: a well-formedness constraint will, ultimately, 
reduce to the constraint of the form F {v : B | £"} and so it will amount to check if the type bool can 
be derived for E under F; for the subtyping case, the simplification of constraints will result in a series 
of restrictions of the form F {v : B | Bi} n ... n {v : B | £"„} ^ {v : B | £"(} n ... fl {v : B | B^}, leading 
to check if m A [Bil A ... A [B„l ^ [Bjl A ... A Kl holds. 

Whenever well-formedness constraints are generated, these are solved before the subtyping ones. 
This step ensures only well-formed types are involved in subtyping relations. Well-formedness con¬ 
straints arise when afresh Liquid Intersection Type is generated, since that is when refinement expres¬ 
sions are plugged into a type. Such fresh types will be of the form Ti n ... fi T„, so the solution for a 
constraint of the form F Ti n ... PI is the type H the intersection of all T,- (with !</<«) such 
that F T,-. We assign this solution to a temporary type, denoted by , which will be used during the 
solving of subtyping constraints. 

The subtyping constraints will ensure that inferred types only present refinement expressions cap¬ 
turing the functional behavior of terms. These will be used with A-abstractions, applications and let- 
bindings. Except for applications, subtyping constraints are preceded by the resolution of well-formedness 
restrictions, and so it is the case that subtyping relations will be checked using the temporary type . 

For the case of A-abstractions, after generating the fresh Liquid Intersection Type (x: fi —)■ fl... fl 

(x: —)■ f^), a series of calls to Infer are triggered, which we present via the syntax let t" = Inf er(r;x: 

Q), with 1 <i<n. These calls differ only on the type f, of x pushed into the environment, implying 
that different types for M can be inferred. After solving the well-formedness constraints, we must remove 
from type £/ the refinement expressions that would cause the type to be unsound. We use the notation 
X : Tjt ^ € j?/ to indicate that f] : Zt ^ should be a supertype of , in the sense that it can be 

obtained from using exclusively the rule [^-Elim] (taking an analogy with set theory, f] |x : Tj; —> 
would be a sub set of the intersections of Then, the inferred type will be P| {x : > f(}, such that 

x: Zk ^ ^ and the constraint r-,x : ZtL^ zj^ ^ zj, is valid, that is, the type inferred for M under the 

environment r;x : is a subtype of As an example, consider Q = {v > 0, V < 0,y = 5}, the term 
Ax. —X and F = 0. The inference procedure will start by generating the type: 

(x : {v > 0} {v > 0}) n 

(x : {v > 0} {v < 0}) n 

(x : {v < 0} {v > 0}) n 

(x : {v < 0} {v < 0}) n 

(x: {v>0}^{y = 5})n 
(x: {v<0}^{y = 5})n 
(x: {y = 5}^{v>0})n 
(x: {y = 5}^{v<0})n 
(x: {y = 5}^{y = 5}) 


Then, with well-formedness constraints, and since no variable y is in scope, we are left with: 
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(x : {v > 0} {v > 0}) n 

(x : {v > 0} {v < 0}) n 

(x : {v < 0} {v > 0}) n 

(x : {v < 0} {v < 0}) 

Finally, because of subtyping relations, the inferred type will be: 

(x : {v > 0} {v < 0}) n 

(x : {v < 0} {v > 0}) 

For application and let-bindings, solving subtyping constraints works in a similar manner as for A- 
abstractions. The type of an application is inferred similarly as in |[8|: for the function M with type 
X : Ti ^ Tj' n... n and the argument N with type T, the type of MN is H such that 1 < / < n 

and F T ^ t,- is checked valid. 

3.4 Properties of inference 

We were able to prove that our inference algorithm is sound with respect to the typing rules. 

Lemma 5 (Relation with derivation and well-founded types) If F Fq M : a then o :: Shape(a). 
Proof. By straightforward induction over Fh^Mia. 

Theorem 3 (Soundness of inference) If Infer (r,M,Q) = a, then F Fq M : a. 

Proof By structural induction over M. 

• case M = x\ 

- subcase in which M has a basic type in this case l^(Shape(r),x) = B and so x has type 
{v : B I ^i} n ... n {v : B I which we abbreviate to Tj n • • • n T„. 

The following derivation is then valid 

r(x) = Ti n • • • n t, :: B(V/.1 <i <n) 

--B-Var 

F Fq X : {v : BI V = x} 

- subcase in which x has not a basic type: in this case a = r(x). 

So, the following derivation is valid 

r(x) = a r(x) :: Shape(a) 

--Var 

FF^x: a 

• Case M = c: Easy, by application of the rule [CONST]. 

• Case M = Xx.N: In this case the algorithm computes 

- (x : fi —>■ f() n ... n (x : —7> f') = Fresh(#'(Shape(r), Ax.M),Q) 

By IH 

r;x : f, Fq : t", V/: 1 < / < n (a) 


By Lemma [5] 


t” :: Shape(Tf),V/: 1 < / < n 
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The type £/ restricts the inferred type only to the well formed intersections: F (;c: fi —> fj) n 
... n (a: : —)• f') reduces to: 

{Fh^ 

Consider the sub-set of derivations in (|al) such that F;v : fy t" ^ fj and that respects the type 
£/. We can conclude that fy :: Shape{Tj) as the subtyping relation can be only applied to types 
refining the same ML type. We shall use T to denote Shape(T"). 

We have then a set of derivations of the form 

T;x: TjI-qN : t'I r;x : fy t" ^ f' F;.* : fy fj 

r-,x:fji-^N:fj ri-^x:fy^f' f':: F 

F Xx.N : (x : fy ^ f') 


By LemmaO 


X : fy —7> Tj :: Shape(fy) —>■ Shape(Tj) 

Moreover, Shape(Ty) = T and we shall we use T' to denote Shape( 
By repeated application of the rule [INTERSECT] 


“j)- 


{x : fy —> fy) n ... n (x : fy+* —7> i'j+k) '-T' 

F Lq Xx.N : (x : fy —)■ fj) ... ^ Fq Xx.N : (x : —>■ f'y+i:) 

Intersect -p—-^^- - - 

F Fq Xx.N : (x : fy —)• f^-) FI... (T (x : fy^^, ^ ^j+k) 


• case M = M'N\ By IH 

- F F^ M': (x : Ti ^ Tj') n ... n (x : ^ 0 

- rFniV:T 

Consider ^ the following derivation 

F Fq : T F F^ T ^ Ti 

F Fq, : Ti 


F F^ Xi 


Sub 


For all the T; such that T -< T; we have a derivation of the form 

F Fq M' : (x : Ti ^ t[ ) H ... H (x : T„ —> T])) 

F F*^ (x: Ti ^ t[ ) n ... n (x : T„ ^ t') -< (x: T; ^ t') F F (x : t, t/) 
Sub -ri— 7 —:- r - 

_ rF^M':(x:T,-^T/) _ 

rF^MW:T'[iV/x] 


— App 


Let be the previous derivation. For each t,- that satisfy T -< T, we have a derivation of the 
previous form. 

By Lemma [5] 

t;[A^/x] :: Shape(T'[A^/x]) 

and we shall use T to denote Shape(T/[A^/x]). So, by repeated application of the rule [INTERSECT] 
the following derivation is valid 

... ^;+y <[iV/x]n...nT'^y[iV/x]::r 

-—;- - ——-;—7— X - -Intersect 

FF^M'iV:T/[iV/x]n...nT'^_y[iV/x] 

By the definition of substitution we have t/[A^/x] fl... n xl_^_j[N/x] = (t/ FI... FI T/^y)[A^/x], which 
is precisely the inferred type. 
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case M = let;c = M'inN: o is of the form f" n ... fl f". By IH 

- rhnM':Ti 

- r-x : Ti h|^ : T2 

The type £/ stands for the set of f, such that F f,, which by the definition of well formed type 
we have 


WF-Intersect 




F h" f 

In 


F f' n... n f' 

‘1 wi 


(b) 


Now we consider all Tj in £/ such that F;;c: Ti T 2 -< fj. We have that F fy as this is a type 

taken from £/. We then have a series of derivations of the form 

F;;c : Ti hS N : T2 F;x : Ti T 2 ^ ty Fh'^fy 

Sub-- 

r-,x:Zi PqN-.Zj 

By LemmaO 

fy :: Shape(fy) 

and we will use T for Shape(fy). By repeated application of the rule [INTERSECT] 

F;;c: Ti fy, ... F;.r : Tj hgN : fy, fy, n ... n fy F 


Intersect 


r-x:Ti h^N:fy, n...nfy, 


The following derivation is then valid 


Let 


FhS M':Ti 


_(C) 

r;x:Tih^Af:-fy,n...nfy, rh^fy,n...nfy, 
r l-Q let jc = M' in N : fy, n... n fy^. 


The derivation (c) follows by (0, since it is the exact same derivations but now we only consider 
the fy such that F;x : Ti Fq T 2 ^ T;. i-C- we intersect a sub-set of the types in (0. 

• case M = [Aa]M': By IH 


The following derivation is valid 

F ho M' : a a 0 F 

-;-Gen 

Fh!^ M':Va.a 


• case M = By IH 

Fh^ M'lVa.a 

Since t' = Fresh(r,Q), then T = Shape(T'). 

t' is of the form n .. . n T,^. The type £/ stands for the set of all t/ such that F h^ t/, so it is a 
sub-type of tJ fl... fl t'. Then, the following derivation is valid 

WF-Intersect 

Fh^r/ ... Fh^T^^. 

rhg,M':Va.(7 Fh^ T'n...nT', ,■ Shape(T'n...nTL,-) = 7’ 

Inst- — - - - — - 

F h^ [t]M' : ( 7 [t' n... n r'i+j/a] 


□ 
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Qualifiers 

{ 

V >= 0, 

V <= 0 

} 

val mul = \x . * X X 
val neg = \x. - x 

Figure 7: File accepted by the lisette tool: a set of logical qualifiers and a program written in tiny-ML. 

3.5 The lisette tool 

In order to automate all the proof-and-typing process required for Liquid Intersection Types inference, 
we implemented a prototype tool that we baptized lisette (Liquid interSEction TypEsjl. 

The purpose of lisette is to parse a program written in a ME-like language (which we shall desig¬ 
nate tiny-ML) plus a set of logical qualifiers and infer an appropriafe Eiquid Infersecfion Type for fhaf 
program, requiring no furfher assisfance from fhe user. This fool works as follows: 

1 . lisette parses fhe finy-ME file (program plus qualifiers) and produces ifs A-normal form version; 

2. using Damas-Milner inference engine, an ME fype is compufed for each sub-ferm in fhe program; 

3. using fhe Fresh(-, •) funcfion, fhe Eiquid Infersecfion Type confaining all possible combinafions of 
qualifiers is generafed and assigned fo each sub-ferm; 

4. fhen, depending on which ferm is being processed, a sef of well-formedness consfrainfs are gener¬ 
ated, solved by fesfing if for all refinemenl expressions the type bool can be derived; 

5. to respect the relations between types, a set of subtyping constraints is computed and translated to 
an equivalent logical formula; 

6. using the logic of the Why3 platform lH |5l as a back-end, we use several automatic theorem 
pro vers to test the validity of the generated sub typing constraints; 

7. finally, combining fhe resulfs of solving well-formedness and subfyping consfrainfs, fhe final Eiq¬ 
uid Infersecfion Type is assigned fo fhe corresponding sub-ferm. 

Our use of fhe Why3 plafform API is mofivafed by fhe facf thaf ifs infernal logic can fargef multiple 
provers. This allows fhe user of lisette to experiment with different provers, comparing how well they 
perform in solving the generated constraints. If the user does not specify a particular prover to be used, 
then lisette tries to solve a constraint by using all the available provers, stopping with the first one that is 
able to prove the validity of the constraint. If none returns a positive answer, that constraint is marked as 
false. Another advantage of using Why3 is that when designing the tool there is no need to worry about 
the different input languages of each different prover, being enough to implement a single translation 
function from the language of Eiquid Intersection Types to Why3 terms. 

As mentioned, this tool accepts a file confaining a sef of logical qualifiers and a program wriffen 
in finy-ME, such as fhe one in Eigure|7] Eor fhis example we have Q = {v>0,v<0} and fhe terms 
composing fhe program are neg = Xx. —x and mul = Xx. *xx. Using fhe supplied sef, lisette will produce 
the following output: 

^http: //www.dcc .fc.up.pt/~mariopereira/lisette . tcir. gz 
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Inference 

resull 








mul 

: (x: 

{V : 

inf 

1 (v>=0)}- 

-> 

{v: 

inf 

1 (v>=0)}) A 


(x: 

{V : 

inf 

o 

II 

V 

> 

-> 

{v: 

inf 

1 (v>=0)}) 

neg 

: (x: 

{V : 

inf 

o 

II 

V 

> 

-> 

{v: 

inf 

1 (v>=0)}) A 


(x: 

{V : 

inf 

1 (v>=0)}- 

-> 

{v: 

inf 

1 (v<=0)}) 


At the end, lisette is able to infer sound and expressive Liquid Intersection Types for the terms mul and 
neg. 


4 Conclusion and future work 

We presented a new type system supporting functional descriptions, via refinement types, and offering 
the expressiveness of intersection types. We believe our type system can be used to derive more precise 
types than previous refinement type systems, whilst maintaining type-checking and inference decidable. 
Liquid Types l!T5ll tend to infer poorly accurate and even meaningless refinement types for some terms 
(leading to the absence of principal types), which we preclude due to the precision of intersection in 
types. Refinement types for algebraic data-types [8] are precise and present desirable properties such as 
principality and decidable inference, though it is our believe that logical predicates are a more natural 
way to specify functional behavior of programs. General refinement types ifTTTl use a very expressive 
annotations language, allowing to assign very precise types to programs, yet with the serious drawback 
of undecidable type-checking and inference. With Liquid Intersection Types we maintain our predicates 
language simple, while being able to automatically infer very accurate and meaningful refinement types. 

To design a decidable system we adopted a style closely related to Liquid Types: the refinement 
expressions presented in types are exclusively collected from Q, a global set of logical qualifiers, and fhe 
subfyping is decidable. We also impose fhaf fhe fype of an expression musf fhe infersecfion of refinemenfs 
fo ifs ML fype, infersecfing only fypes of fhe same form. 

We also proposed an inference algorifhm for Liquid Infersecfion Types. This algorifhm fakes as inpuf 
an environmenf T, a ferm M and fhe sef of qualifiers Q, producing fhe correspondenf Liquid Infersecfion 
Type. Our inference algorifhm uses fhe W algorifhm fo infer fhe shape of a Liquid Infersecfion Type, 
which is fhe ML fype for fhaf ferm. To defermine which refinemenf expressions can be plugged info a 
fype, fhe algorifhm produces a series of well-formedness and subfyping consfrainfs, solving fhem imme¬ 
diately afler fheir generafion. We have been able fo prove fhaf our algorifhm is sound wifh respecf fo fhe 
conceived fyping rules. 

Currenf and fulure work includes fhe sfudy of complefeness of fype inference for our sysfem and fo 
extend decidable infersecfion fype systems (of finite ranks IHITOl) wifh fype refinemenf predicafes. 
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